home *** CD-ROM | disk | FTP | other *** search
- Path: news.sprintlink.net!datalytics!usenet
- From: Rob Stewart <stew@datalytics.com>
- Newsgroups: comp.lang.c,comp.programming
- Subject: Re: Assertive or Defensive?
- Date: Tue, 02 Apr 1996 12:51:45 -0500
- Organization: Datalytics, Inc
- Message-ID: <31616931.2469@datalytics.com>
- References: <4ioggn$3sf@dazzle.east-tenn-st.edu>
- <4itcs2$po3@B1FF.mindspring.com> <31546257.11E1@olympic.net> <htlokjqx7y.fsf@calph.physics.sunysb.edu>
- NNTP-Posting-Host: 204.62.224.71
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 2.0 (WinNT; I)
-
- Eugene Tyurin wrote:
- >
- > Basically, they say: we have 2 versions of code -- development and
- > production (they call it "slick"). Production version has minimum of
- > diagnostics, because who cares if a program crashes once in a while
- > instead of exiting with proper message -- user can always reboot.
- >
-
- You must carefully select when to use assertions and when to use
- runtime validation. If you test your debug version of the
- software, you'll discover the mistakes and misuse of things.
- The code thus helps you correct bugs before you ship the
- product. This is far preferable to a program that reports
- an error that says, in effect, "One of our developers made a
- mistake by passing that value to this function. You'll have to
- notify our technical support department, then wait for our next
- patch or upgrade--for which you'll probably need to pay--to get
- the correction."
-
- You can even use an assertion to call attention to error
- handling in your code. For example, say you expect that a
- certain condition won't occur in a proper program, but can't be
- certain of it. Furthermore, suppose that the results of that
- condition are disastrous. You can code an assertion to call
- attention to the mistake, but also code runtime handling of the
- error. This prevents the production version of the program from
- crashing, but also catches most circumstances in which the
- erroneous value was given.
-
- You can't eliminate runtime error checking. There are some
- conditions that you simply can't account for. You must,
- therefore, choose what can be eliminated through the use of
- assertions and debugging, and what cannot.
-
- > Last time I used assert was to detect numerical overflow. I found the
- > problem and corrected it. After that assert became redundant.
-
- If you ever change (or someone else changes) your code for
- maintenance reasons, the assertion will still be there to tell
- you when you've introduced the problem again. Of course, if you
- have a test driver for each function to supply inputs that test
- all aspects of your function and validate its processing, AND
- you use it whenever you make changes, then you don't need an
- assertion to detect the problem.
-
- When writing code shared by many developers, assertions can
- communicate and enforce one developer's intention as to what
- should enter or leave a function. Furthermore, assertions can
- help you ensure that the intermediate steps are consistent with
- your goal.
-
- --
- Robert Stewart | My opinions are usually my own.
- Datalytics, Inc. | stew@datalytics.com
-